Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0055/521.txt

Text File | 1997-04-16 | 22KB | 590 lines

Via:      UK.AC.EARN-RELAY; 16 OCT 89 11:45:47 GMT
Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 1761; Sun, 15
          Oct 89 05:28:38 BS
Received: from CEARN.cern.ch by UKACRL.BITNET (Mailer X1.25) with BSMTP id
          0454; Sun, 15 Oct 89 05:28:36 B
Received: by CEARN (Mailer R2.03B) id 8655; Sun, 15 Oct 89 05:28:30 GVA
Date:     Sat, 14 Oct 89 15:00:10 MDT
Reply-To: [e-mail]-SIMTEL20
Sender:   INFO-ATARI16 Discussion <[e-mail]>
Comments: Warning -- original Sender: tag was INFO-A16@MARIST
From:     [e-mail]-SIMTEL20
Subject:  INFO-ATARI16 Digest V89 #521
Comments: To: [e-mail]

INFO-ATARI16 Digest         Sat, 14 Oct 89       Volume 89 : Issue 521

Today's Topics:
                           1040 ST for sale
                  520STFM FOR SALE   (w/many xtras)
                             Event multi
                         Laser C and TOS 1.4
                             Laser C bugs
            TOS 1.4, memory chips, T16...and the Mega2 STs
              Wanted: Info on DEGAS picture compression
----------------------------------------------------------------------

Date: 13 Oct 89 05:28:56 GMT
From: att!drutx!druks![e-mail]  (CochraneJT)
Subject: 1040 ST for sale

I have a 1040 ST that I no longer need since I'm now
using a Mega 2.  It's in good condition, runs fine
and has been very reliable.  It includes the standard
double sided drive and 1 meg memory, but no monitor.
I would like $400 for it.

If you are interested or have questions about it, I can
be reached at home (most) weekday nights and on weekends at
    303-449-3315
or, if you prefer, you can send me e-mail.


Jim Cochrane

[e-mail]
att!druks!jamesc

------------------------------

Date: 14 Oct 89 20:21:58 GMT
From:
 gem.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!geoffs@tu
t.cis.ohio-state.edu  (Geoffrey Sauerborn )
Subject: 520STFM FOR SALE   (w/many xtras)

FOR SALE:    Color Atari 520STFM SYSTEM w/RAM board upgrade.
                     (also w/PC DITTO and 5 1/4" floppy!)
                     (software and over 50 disks!)

    $600 plus shipping.

    Atari 520STFM system includes:.
      Color monitor  (SC1224).
      EZRAM II board - 1 to 2.5 meg RAM upgrade.
      Late model (only 2 years old)-(Rev.H) includes Television RF output.
      External SS    400K SF354      3 1/2" floppy disk drive.
     *NEW External DS/DD 360K I.B. DRIVE  5 1/4" floppy disk drive.*
      TOS in ROM, Atari Basic, DR Logo., and of course GEM in ROM & mouse.

    Lots of software
       Utilities:
           *PC DITTO*
        PRINTMASTER PLUS
        HIPPO WORD
        ST LEDGER
        Original Atari Development System Documentation & Utilities.
         (plus C Compiler updated to ver 4.14 1986).
       GAMES
           FLIGHT SIMULATOR II (Plus east coast Scenery Disk 7).
        HARRIER STRIKE MISSION (needs $5 disk replacement).


    I will through in:
       OVER 50 disks!!! PD or Shareware software. Archived and indexed.
        includes:
        UNITERM(using now),MICROEMACS 3.91/4,Compilers,Drawing...more.
        HACK,LARN,RISK,MONOWARE,WHEEL OF FORTUNE,... too many to name.
        3 Flip File dust cover 3.5 disk storage containers.
        16 256K DRAM chips (enough for 1meg upgrade).
           [ Some of these chips are flakey so they are not
             included with the RAM board.   I don't have a
             chip tester to pick out the bad ones.  Maybe it
             can be done in software? ]
        All items shipped in original boxes with manuals.
--
---> [e-mail]    -or-    [e-mail]
--

------------------------------

Date: 14 Oct 89 09:10:54 GMT
From: agate!stew.ssl.berkeley.edu![e-mail]  (Eric C. Olson)
Subject: Event multi

Once again I'm trying to make GEM AES do something useful.  Its
now quite late, and the situation looks grim ...

Is it possible to check the state of EITHER mouse button using
event_multi?  Or any other (documented) routine?

I have found that specifying  0x3 for the bstate parameter and
0x3 for the bmask parameter only matchs button chords.  How do
I tell event_multi to wait for a left OR a right mouse click
(or both)?

Thanks in advance,
Eric



Eric
[e-mail]

------------------------------

Date: 14 Oct 89 02:51:14 GMT
From:
 gem.mps.ohio-state.edu!ginosko!shadooby!mailrus!jarvis.csri.toronto.edu!utgpu!w
atmath!julian!uwovax![e-mail]
Subject: Laser C and TOS 1.4

In article <[e-mail]>, [e-mail] (Darek Mihocka)
 writes:
> [ some very accurate comments on Laser ]
>    ... I just
> stick to assembler for now while somebody writes a decent C compiler for
> the ST.

I agree with you on Laser; it had promise, but the buggy code generation,
incomplete library, and weird disk cache eventually caused me to give
up on it. Fortunately, there is an alternative; the GNU C Compiler. It's
a huge memory pig (you really need 2 megabytes to run it) but it produces
very good code, is ANSI compatible, and now comes with an (almost) ANSI
and Unix compatible library. And the price is right... it's free! (Source
is available too, and it's being actively supported by the Free Software
Foundation). The current version is 1.36, available from dsrgsun.ces.cwru.edu
and (I think) terminator.
--
Eric Smith
[e-mail]
[e-mail]

------------------------------

Date: 14 Oct 89 08:43:52 GMT
From: ubc-cs!grads.cs.ubc.ca![e-mail]  (Michael Horsch)
Subject: Laser C bugs

In article <[e-mail]> [e-mail] (Darek Mihocka) writes:

[some gripes about Laser C... The ones I am addressing are not
 edited out (how's that for being contrapositive!)]

>          The C code generation has some problems when you get
>pointers to structures containing pointers, etc.

    I have never had this one, and I've been messing
    around a lot with objects, and structures which
    contain pointers to objects, and linked lists of
    trees whose nodes point to objects, and...

>                                                 What also irritates
>me is that if you have a string constant and you forget to put in the
>closing quotation marks, it crashes.

    Not this either. I always forget to close qoutes. Sometimes
    I forget the difference between " and '. I only get
    compiler errors.

>                                     All of these bugs have been present
>since Megamax C, I keep reporting them, and they keep ignoring them or
>telling me they're fixed. That's pissing me off to no end, because otherwise
>I like the package a lot.

    Keep reporting them. I would too, if I found any. But mostly
    I find my own bugs. No implication implied.

>
>The disk cache tends to mess up when you are low on RAM and compiling a
>large program (i.e. more than one module or more than a "hello world"
>skeleton).

    I assume the parenthetical remark to be slightly sarcastic, but
    your argument about low RAM behaviour makes sense to me (I
    have a Mega2, so this is never a problem). I agree
    with an earlier posting in which you suggested that
    the cache be optional.

>Sure the cache is great if you're compiling off floppy, but you're not going
>to develop a large project on floppy.

    Why not? The disk cache and RAM resident tools make this
    completely reasonable. A little painful at the start of
    a programming session (and after unrecoverable errors),
    for sure, but certainly not completely unthinkable.
    Especially for those (i.e. me) who (perhaps) misguidedly
    purchased a machine with more RAM instead of a hard disk.

    I am not a real C programmer, that is, I don't spend months
    working on real projects (in fact, I'm a Prolog hacker
    `by trade' :-) and my Mega2 is somewhat ignobly
    reduced to a real slow terminal for most of its use)
    so I consider one-floppy development adequate for my
    medium sized hacks ---but only with the cache, etc.
>
>- Darek

Mike ("By trade?" --Well, it beats working for a living!)
--
Michael C. Horsch       Disclaimer: I'm not thinking for anyone else but
[e-mail]                    me; I'm having enough trouble as it is!

Dept. of Computer Science
University of British Columbia
--
If you don't waste time with your friends, you're just wasting your time.
--

------------------------------

Date: 14 OCT 89 11:32:06 CST
From: Z4648252 <[e-mail]>
Subject: TOS 1.4, memory chips, T16...and the Mega2 STs

    Can anyone shed some light preparing a Mega2 ST that has six ROM
sockets for use with the T16 and upgrading the Mega2's memory to four meg?
    I've been reading conflicting data about what brand and speed memory
chips to use if one wants to use the T16.  I've also been reading that
the T16 is happier if used with fast ROM, that is, copying the original
TOS 1.4 EPROM into faster EPROM chips.
    Also, should the older 'Atari' blitter be replaced with the newer?
    Incidentally, the 74LS373 chips have been replaced.  I had problems
with Spectre until they were.
    SIGH...this is a terribly worded letter.  Basically, I'm only
asking:

1.  What memory chips should be used for upgrading the ST2 to a ST4
    if used with the T16?
2.  Should the chipped TOS 1.4 be transferred to fast EPROMS to gain
    maximum results from the T16?
3.  Should the Atari blitter be replaced with the newer?
4.  Yes, the 74LS373 chips have been replaced.

Larry Rymal:  |East Texas Atari 68NNNers| <[e-mail]>

------------------------------

Date: 14 Oct 89 20:00:49 GMT
From: pasteur!cory.Berkeley.EDU![e-mail]  (Jonathan Lemon)
Subject: Wanted: Info on DEGAS picture compression

In article <[e-mail]> [e-mail] writes:
>Wayne Schellekens asks:
>
>>Does anyone have any information as to how DEGAS compresses its
>>picture files?
>
>His file "ST Picture Formats" may be available on the ST archives, or I know
>it's available on CompuServe.. (since I uploaded it there)
>
Also right here.


                           ST Picture Formats
                           ------------------
                              Compiled by:
                              Dave Baggett
                         (arpanet: [e-mail])

                   (Please report errors or additions)

                              CONTRIBUTORS

            Phil Blanchfield    David Brooks    Neil Forsyth
              Ken MacLeod     Darek Mihocka    George Seto
               Joe Smith    Greg Wageman    Gerry Wheeler


                        Introductory information
                        ------------------------
word    = 2 bytes
long    = 4 bytes
palette = Hardware color palette, stored as 16 words.  First word is
          color register zero (background), last word is color register
          15.  Each word has the form:

          Bit:  (MSB) 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 (LSB)
                      -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
                       0  0  0  0  0 R2 R1 R0  0 G2 G1 G0  0 B2 B1 B0

          R2 = MSB of red intensity
          R0 = LSB of red intensity

          G2 = MSB of green intensity
          G0 = LSB of green intensity

          B2 = MSB of blue intensity
          B0 = LSB of blue intensity

          Intensity ranges from 0 (color not present) to 7 (highest
          intensity).

          Example: ? red = 7, green = 3, blue = 5 ? -> 0735 (hex)

          Caveat:  It is wise to mask off the upper four bits of each
                   palette entry, since a few programs store special
                   information there (most notably Art Studio).


                             The Formats
                             -----------

<NEOChrome>

1 long          resolution (0 = low res, 1 = medium res, 2 = high res)
16 words        palette
12 bytes        filename ("        .   ")
1 byte          Left color animation limit (starting color number)
1 byte          Right color animation limit (ending color number)
1 byte          color rotation speed
1 byte          color rotation direction
1 word          color rotation duration (number of iterations)
18 longs        reserved for expansion
16000 words     picture data (screen memory)
-----------
32128 bytes     total


<NEOChrome Animation>

NOTE:      To get this feature on versions 0.9 and later select the Grabber
        icon and click the right mouse button in the eye of the second R in
        the word GRABBER.

1 long          magic number BABEEBEA (hex) (seems to be ignored)
1 word          width of sprite in bytes (always divisible by 8)
1 word          height of sprite in scan lines
1 word          size of sprite in bytes + 10 (!)
1 word          x coordinate of sprite (must be divisible by 16) - 1
1 word          y coordinate of sprite - 1
1 word          number of frames
1 word          animation speed (larger means slower)
1 long          reserved; should be zero
--------
44 bytes        total for header

? words         sprite image data (words of screen memory) for each sprite,
                in order


<DEGAS>

1 word          resolution (0 = low res, 1 = medium res, 2 = high res)
                Other bits may be used in the future; use a simple bit
                test rather than checking for specific word values.
16 words        palette
16000 words     picture data (screen memory)
-----------
32034 bytes     total


<DEGAS Elite (Uncompressed)>

1 word          resolution (0 = low res, 1 = medium res, 2 = high res)
                Other bits may be used in the future; use a simple bit
                test rather than checking for specific word values.
16 words        palette
16000 words     picture data (screen memory)
4 words         left color animtion limit table (starting color numbers)
4 words         right color animation limit table (ending color numbers)
4 words         animation channel direction flag (0 = left, 1 = off, 2 = right)
4 words         animation channel delay in 1/60's of a second. [0 - 128]
-----------
32066 bytes     total


<DEGAS Elite (Compressed)>

1 word          resolution (same as Degas, but high order bit is set;
                i.e., hex 8000 = low res, hex 8001 = medium res,
                hex 8002 = high res).  Other bits may be used in the
                future; use a simple bit test rather than checking
                for specific word values.
16 words        palette
< 32000 bytes   control bytes
4 words         left color animtion limit table (starting color numbers)
4 words         right color animation limit table (ending color numbers)
4 words         animation channel direction flag (0 = left, 1 = off, 2 = right)
4 words         animation channel delay in 1/60's of a second. [0 - 128]
-----------
< 32066 bytes   total

Control byte meanings:

        For a given control byte, x:

        0 <= x <= 127   Use the next x + 1 bytes literally (no repetition)
        -127 <= x <= -1 Use the next byte -x + 1 times
        -128            No operation (ignore)

Compression Scheme:

   Each scan line is compressed separately; i.e., all data for a given
scan line appears before any data for the next scan line.  The scan lines
are specified from top to bottom (i.e., 0 is first).  For each scan line,
all the data for a given bit plane appears before any data for the next
higher order bit plane.
   To clarify:  The first data in the file will be the data for the lowest
order bit plane of scan line zero, followed by the data for the next higher
order bit plane of scan line zero, etc., until all bit planes have been
specified for scan line zero.  The next data in the file will be the data
for the lowest order bit plane of scan line one, followed by the data for
the next higher order bit plane of scan line one, etc., until all bit planes
have been specified for all scan lines.


<C.O.L.R. Object Editor Mural>

16000 words     picture data (screen memory)
                (palettes are stored in separate files)
-----------
32000 bytes     total


<Tiny>

1 byte          resolution (same as NEO, but +3 indicates rotation
                information also follows)

If resolution > 2 ?
1 byte          left and right color animation limits.  High 4 bits
                hold left (start) limit; low 4 bits hold right (end)
                limit
1 byte          direction and speed of color animation (negative value
                indicates left, positive indicates right, absolute value
                is delay in 1/60's of a second.
1 word          color rotation duration (number of iterations)
?

1 word          number of control bytes
1 word          number of data bytes
16 words        palette
3-10667 bytes   control bytes
2-32000 bytes   data bytes
-------------
42-32044 bytes  total

Control byte meanings:

        For a given control byte, x:

        x < 0   Absolute value specifies the number of unique words to
                take from the data section (from 1 to 127)
        x = 0   1 long is taken from the control section which specifies
                the number of times to repeat the next data word (from
                128 to 32767)
        x = 1   1 word is taken from the control section which specifies
                the number of unique words to be taken from the data
                section (from 128 - 32767)
        x > 1   Specifies the number of times to repeat the next word
                taken from the data section (from 2 to 127)


<Spectrum 512 (Uncompressed)>

80 words        first scan line of picture (unused) -- should be zeroes
15920 words     picture data (screen memory) for scan lines 1 through 199
9552 words      3 palettes for each scan line (the top scan line is
                not included because Spectrum 512 can't display it)
-----------
51104 bytes     total


<Spectrum 512 (Compressed)>

1 word          5350 (hex) ("SP")
1 word          0 (reserved for future use)
1 long          length of data bit map
1 long          length of color bit map
<= 32092 bytes  compressed data bit map
<= 17910 bytes  compressed color bit map
--------------
< 50014 bytes   total

Data compression:

   Compression is via a modified run length encoding (RLE) scheme.  The
data map is stored as a sequence of records.  Each record consists of a
header byte followed by one or more data bytes.  The meaning of the header
byte is as follows:

        For a given header byte, x:

        0 <= x < 127    Use the next x + 1 bytes literally (no repetition)
        -128 <= x < 0   Use the next byte -x + 2 times

The data appears in the following order:

        1. Picture data, bit plane 0, scan lines 1 - 199
        2. Picture data, bit plane 1, scan lines 1 - 199
        3. Picture data, bit plane 2, scan lines 1 - 199
        4. Picture data, bit plane 3, scan lines 1 - 199

Decompression of data ends when 31840 data bytes have been used.

Color map compression:

   Each 16-word palette is compressed separately.  There are three
palettes for each scan line (597 total).  The color map is stored as a
sequence of records.  Each record starts with a 1-word bit vector which
specifies which of the 16 palette entries are included in the data
following the bit vector (1 = included, 0 = not included; i.e., stays
the same).  The least significant bit of the bit vector refers to
palette entry zero, while the most significant bit refers to palette
entry 15.  Bit 15 must be zero, since Spectrum 512 does not use palette
entry 15.  Bit 0 should also be zero, since Spectrum 512 always makes the
background color black.
   The words specifying the values for the palette entries indicated in
the bit vector follow the bit vector itself, in order (0 - 15).


<Animatic Film>

1 word          number of frames
16 words        palette
1 word          speed (0 - 99; higher value is faster)
1 word          direction (0 = forwards, 1 = backwards)
1 word          end action (what to do after the last frame)
                0 = pause, then repeat from beginning
                1 = immediately repeat from beginning
                2 = reverse
1 word          width of film in pixels
1 word          height of film in pixels
1 word          version number (major)
1 word          version number (minor)
1 long          magic number 27182818 (hex)
3 longs         reserved (should be all zeros)
--------
32 words        total for header

? words         image data (words of screen memory) for each frame, in order


<MacPaint>

header ?
1 long          version number (if zero, entire header is ignored)
38 * 2 longs    pattern data (anyone know how to use this?)
51 longs        reserved
?
< 51200 bytes   compressed bitmap data
-------------
< 51716 bytes   total

Bitmap compression:

   The bitmap data is for a 576 pixel by 720 pixel image.  The data is
stored as a sequence of records.  Each record consists of a control
byte followed by one or more data bytes.  The meaning of the control
byte is as follows:

        For a given control byte, x:

        0 < x < 127     Use the next x + 1 bytes literally (no repetition)
        -128 <= x <= 0  Use the next byte -x + 1 times

There are 72 bytes per scan line.  Each bit represents one pixel; 0 = white,
1 = black.


Version of Fri Sep  2 01:31:21 EDT 1988
---------------------------- >8 -------------------------------------
--
Jonathan   ...ucbvax!cory!jlemon   or    [e-mail]

------------------------------

End of INFO-ATARI16 Digest V89 Issue #521
*****************************************